Management 3.0: Leading Agile Developers, Developing Agile Leaders
https://images-na.ssl-images-amazon.com/images/I/417UtzrbiSL._SX380_BO1,204,203,200_.jpg
読書 : 2020-08-22 〜
感想
内容メモ
前書き
マネジメントの本は嫌いだけどこの本は良い
赤の女王仮説 (the Red Queen Race hypothesis) や正八胞体 (tesseract) の描写や Drunkard's Walk についての話があり、賢い チームサイズと動機づけの問題から、組織のスケールアップとスケールアウトについてまで扱っている
最近のアジャイル開発は、複雑なシステムの要求やアーキテクトを線形なアプローチ (トップダウンで階層構造型の、決定論的なアプローチ) で可能だという考え方を否定している
それは組織にも言えるはず
リスク管理、見積もり、スケジューリング、進捗状況のモニタリングなどの伝統的なプロジェクトマネジメントの話は出てこない
それらは必要であろうが、それだけでは十分ではない
序文
本書はアジャイルマネジメント (アジャイルソフトウェア開発のカウンターパート) の本
組織がアジャイル開発をするのであれば、チームリーダーや開発者のマネジャーはアジャイルマネジメントを避けては通れない
アジャイルになりたいマネジャーや、マネジメントを学びたいアジャイル開発者が対象
タイトルについて
マネジメント 1.0 : 階層構造的
科学的なマネジメントと呼ぶ人もいる; 命令と制御と呼ぶ人もいる
組織はトップダウン式に設計・マネジメントされて、力はごく少数のものの手にある
マネジメント 2.0 : 流行
マネジメント 1.0 の問題に対処するため、Balanced Scorecard、Six Sigma、Theory of Constraints、Total Quality Management などを追加して半科学的な状態にしたもの
多少は改善しているが根本解決はしていない
マネジメント 3.0 : 複雑性
組織はネットワークであり、マネジメントとは部門と利益ではなく人と人同士の関係が主である
Chapter 1 : Why Things Are Not That Simple
ソフトウェア開発の最善の方法はアジャイルソフトウェア開発であるが、古いスタイルのマネジメントが、世界中でアジャイルソフトウェア開発を採用する上で最大の障害になっている
アジャイルマネジャーになるために、人とシステム、そして人がシステムについて考えることについて学ぶ必要がある
マネジメント対象について知る必要がある
実際、科学分野で因果決定論は多くの成果をあげている
ソフトウェア開発でもソフトウェアの動作について設計し、計画し、予測できる
しかし、因果決定論だけでは不十分
ソフトウェアプロジェクトの機能、品質、時間、リソースの完全な組み合わせを予測することができない
いつ、どの程度、顧客獲得できるかどうかといったことも予測できない
複雑性があるから
大きな数と複雑性を混同する人もいるが、大きくなくても複雑にはなりうる
20 世紀に複雑性の研究は大きく進んだ → 複雑性理論 我々は複雑性より因果関係を好みやすい
人間の脳は、すべてのものに目的と因果関係を見出すように設計されているようだ
物音がしたらそこに誰かが居ると思い込む、みたいな、因果関係の過大評価
人の危機回避のために発達した特性？ なんかこの話どこかでも見たな nobuoka.icon
私たちの直線的な思考は、世界を、単純な原因と単純な効果を持つ、簡単に説明可能な出来事に満ちた場所と見なしがち
エンジニアや技術的な思考を持った人は、制御の概念に影響を受けやすい
マネジメントにおける因果関係 → 望ましい結果を得るため、マネジャーに先行設計と綿密な計画を求める
ある程度は有益だが、あらゆるところで使えるわけではない
全体論 (Holism) : システムの動作は構成部品からだけでは完全には決定できない、という考え 複雑性の科学者は、複雑性がこの 2 つを橋渡しすると考えている
階層的還元主義 (hierarchical reductionism) : 複雑なシステムは階層で記述でき、それぞれの階層はその一段下の階層の部品で記述できる (が、より下の階層の部品では記述できない) という中間的な思想
レベルごとに新しく不可逆な特性を持つこともありうる
階層型マネジメント (Hierarchical Management)
階層システムのあるレベルについて全て知っている人が、そのシステムのより下位または上位のレベルについて扱えるわけではない
マネジャーには人のマネジメント (マネジャーが扱うべきレベルより下位のレベル) とは別の技能が必要だが、基礎レベルの知識は有用かも
詳細が漏れることもある
アジャイルマネジメント
階層型マネジメントが複雑性と非線形思考を包含するとアジャイルマネジメントになる
アジャイルソフトウェア開発の仲間
アジャイルソフトウェア開発のルーツは複雑性理論 : プロジェクトの成功には因果関係の決定論では不十分
自己組織化や創発は、複雑性科学の文献からコピーされたもの
なぜなぜ分析のような方法が単純な因果関係にバイアスをかけていないか気を付ける必要がある 本書はより良いマネジャーになることを助ける
Martie : Management 3.0 のモデルらしい。 かわいい怪物っぽい？ https://1qjpt15fhlq3xjfpm2utibj1-wpengine.netdna-ssl.com/wp-content/uploads/2018/12/martie-management-model-246x300.png
Energize people : 4 章と 5 章
Empower teams : 6 章と 7 章
Align constraints : 8 章と 9 章
Develop competence : 10 章と 11 章
Grow structure : 12 章と 13 章
Improve everything : 14 章と 15 章
Chapter 2. Agile Software Development
アジャイル宣言は、多くの人にとっては形式的なアプローチの官僚主義に対する反動に見えていた
実際には、ソフトウェア開発の世界のアドホックな側面を支配していた、規律のないプログラマー、「混沌とした」 プロセス、低品質の製品に対してもスタンスを取っていた
アジャイルのリーダーたちは、構造と非構造の間、秩序と混沌の間には中道があることを理解していた
計画性、予測可能性、文書化に対する多くの組織のニーズ
「変更に反対する経営陣」、「管理統制の喪失」、「エンジニアリングの規律の欠如」、「チームの変更に反対するチーム」、「エンジニアリング人材の質」
→ 世界中のマネージャーがアジャイルソフトウェア開発の最大の障害になっている
アジャイルソフトウェア開発は、(ライン) マネジメントの重要性を見落としている
マネジャーがアジャイル組織で何をすべきか、何を期待すべきかを知らないのであれば、アジャイルソフトウェア開発への移行にどのように関わっていくのか？
「マネジャーは不要」 と言っているとしたら、世界中でマネジャーがアジャイルへの移行を妨げていても不思議ではない
世の中では混同されがち → 本書ではこれらを区別する
本書の主な目的は、ラインマネジャー (開発マネジャーとチームリーダーを含む) が、組織の中での自分たちの役割を理解することを助けること
Chapter 3. Complex Systems Theory
境界での複数の相互作用からなり、体験から変化と学習を行う
複雑性理論を組織とマネジメントに適用するのは有益
科学では分野ごとのサイロがあったが、複数分野にまたがる複雑なシステムだと認識されて、理解されやすくなった もともとシステムの要素に着目していたが、要素の組織化に焦点を移した
→ システムが自身をどう形作るか？ システムはどう同定できるか？ どう安定するか？ 環境とどう相互作用するか？ といったコンセプト
研究自体の目的は、そのような制御系のプロセス (実行 (環境への影響を持つ)、センシング (環境の反応の確認)、評価 (ゴールと現在の状態の比較) の繰り返しを含む) を理解すること
ソフトウェア開発チームも、ゴールに向かうシステムで、多くのフィードバックサイクルで自分たちを制御する
そのようなシステムにおいては、情報とコミュニケーションと目的が最も重要な要素
力学系理論 : 一般システム理論とサイバネティクスがシステムの知識体系の両足だとしたら、これが腕の一つ 動的システムは多くの状態を持つ (安定しているものもそうでないものも)
システムの一部が時間経過しない場合や、不安定になった後に常にオリジナルの値に戻る場合、それらの安定した状態をアトラクタ (attractor; 惹きつけるもの) という
ソフトウェア開発との関係は？ : なぜ一部のプロジェクトは安定していて、他はそうでないのかを説明したり、組織の振る舞いを変更することができないのはなぜなのか (元の振る舞いに戻ってしまう理由) を説明する
ソフトウェアシステムの進化はダーウィンの言う進化とは別物ではあるが、時間経過によるシステムの成長、生存、そして適応を理解するのに有用
動的システムにおける極小の変化は、後で大きな結果をもたらしうる
この予測不可能性は、プロジェクトマネジャーやラインマネジャーにはあまり知られていない
カオス理論は複雑性理論の前身
システムについての他の研究
Simplicity の概念
complex と complicated の違いを理解しておくことが重要
理解しやすいかどうか (構造) と、予測しやすいかどうか (振る舞い)
Simple = 理解しやすい / Complicated = 理解が難しい
Ordered = 完全に予測可能 / Complex = 一部予測可能 / Chaotic = 予測不可能
https://gyazo.com/03c1bf5e4acefcfc66c2766e7d63797a
他のモデル
agreement と uncertainty (不確実性) の 2 軸で分けたものもある
いずれも完全ではないが有用
Simplification : 構造を理解しやすくする
Linearization : 振る舞いを予測可能にする
Complicated なものを Simple にすることを目指すべきだが、そのときに振る舞いが変わるようではいけない、的な話っぽい
ソフトウェア開発チームも含め、本書で扱うのは複雑適応系が多い
学習と適応により、“chaordic processes” という ordered と chaotic の間のちょうどよい場所に自分たちを導く
知識体系ではないけど使えるツール
組織の構造 (循環構造をもち、連動し、時間遅れを伴うパーツ間の関係性を持つ) はしばしば個人よりも重要な、組織に貢献するものである
生産力のある組織は、モデルと計画によってマネージされるものではなく、自己組織化の力と進化によって発生する
Chapter 4 / Chapter 5
Chapter 6 / Chapter 7
Chapter 8 / Chapter 9
Chapter 10 / Chapter 11
Chapter 12 / Chapter 13
Chapter 14 / Chapter 15
Chapter 16 : All Is Wrong, but Some Is Useful
本書全体について
人は組織の最も重要な部分 (4 章、5 章)
マネージャーは、人を活発で創造的でやる気のある状態にする (維持する) ためにできる限りのことをするべし
チームは自己組織化することができる
権限付与、承認、マネジメントからの信頼が必要 (6 章、7 章)
人々と共有リソースを保護し、人々に明確な目的と目標を与える必要 (8 章、9 章)
自己組織化はどこにでも向かいうる
マネジャーは能力の開発に貢献する必要がある (10 章、11 章)
チームメンバーの能力が十分でない場合、チームは目標を達成できない
コミュニケーションを強化する構造を検討することが重要 (12 章、13 章)
多くのチームは複雑な組織の中で活動しているため
人、チーム、組織は、継続的に改善する必要がある (14 章、15 章)
複雑系において、単純で理解しやすい結論は正しくない (16 章)
複雑系のモデルは不完全ではあるが、補完的な視点を提供するので有用な可能性はある
Any two points of view are complementary.
組織とソフトウェアチームは複雑なので、互いに共存し、矛盾する複数のマネジメントのモデルがある
マネジメントについての競合するモデルがあるのと同じく、ソフトウェア開発でも競合がある
「アジャイルであるとは、○○のプラクティスに従うこと」 みたいな思想もある
筆者の考えは、アジャイルであることは絶えず変化する環境で成功を維持すること
どの組織にも適用できるプラクティスなどというものはない
あえて言うと、「どの組織でもこのプラクティスを採用せよ」 というような専門家を捨てること
アジャイル専門家は複雑性理論を知っているべき (ルーツのひとつなので) だが、最近ではそれは期待できない
全てのモデルは間違っているが、コンテキストによっては有益である
複雑性を扱うために理解しておくべきこと
問題には複数の解決策がある
解決策は問題のコンテキストに依存する
コンテキストが変化したら解決策も変化させる必要がある
奇妙な解決策も、どこかでは最良の解決策になりえる
解決策は、環境と解決策自身を変化させる
複雑性を理解する必要がある (どんな状況にも適用できる単純な結論はない)
最善の解決策を予測することはできない